chore: replace cvm-reverse-proxy with attested-tls-proxy#98
chore: replace cvm-reverse-proxy with attested-tls-proxy#98MoeMahhouk wants to merge 2 commits intomainfrom
Conversation
ameba23
left a comment
There was a problem hiding this comment.
Looks great.
One question - do we need to worry about the service needing access to /sys/kernel/config/tsm/report for DCAP attestation? Im not sure whether cvm-reverse-proxy needed this, but attested-tls-proxy definitely does on GCP.
The buildernet service explicitly adds it as a read-write path, presumably because otherwise the service could not access it:
d7b7d72 to
645965b
Compare
Good question! Edit: This PR, is just a drop-in replacement to cvm-reverse-proxy service which wasnt hardened before either. Created an issue for it here #99 to track it |
Summary
Test plan
Local QEMU testing (no TDX, attestation type none):
Inside the VM, the server runs via systemd with these flags:
attested-tls-proxy server
--listen-addr 0.0.0.0:8745
--server-attestation-type auto
--allowed-remote-attestation-type none
127.0.0.1:5001
On the host, start the client:
attested-tls-proxy client
--listen-addr 127.0.0.1:9090
--allowed-remote-attestation-type none
--allow-self-signed
localhost:8745
Then fetch pubkeys through the full chain:
curl http://localhost:9090/pubkey
Production testing (Azure/GCP TDX VM, attestation type auto):
Server runs via systemd with --server-attestation-type auto (detects TDX hardware). On the client machine:
attested-tls-proxy client
--listen-addr 127.0.0.1:9090
--allowed-remote-attestation-type none
--allow-self-signed
<VM_IP>:8745
curl http://localhost:9090/pubkey